Need for Technology Configuration Management

When multiple people operate on the create and modify multiple technology configuration items and assets related to Client’s applications and infrastructure for the same engagement, it can lead to complications unless the changes are controlled. Hence it is essential to place all work products under an appropriate levels of configuration management. Improper configuration management leads to:

• Rework
• Time delay
• Effort overrun
• Multiple rounds of communication, etc.

Technology Configuration Items

The term "technology configuration item" can be applied to anything designated for the application of the elements of technology configuration management and treated as a single entity in the technology configuration management system.

Work products like technology documents, data, models, software source code, etc. created in an engagement are a few examples of technology configuration items. These vary in complexity, type and size. Technology configuration item types can be software, hardware, documentation, network, people, etc.

Naming Conventions

It is important to provide unique naming conventions for technology configuration items. This facilitates easy traceability and avoids confusions. Every engagement must establish its standards for unique naming conventions for each technology configuration item.

Version Control

Versioning is the process of assigning either unique version names or unique version numbers to a work product. Versions of technology configuration items can be defined as an identified work product referenced by a number called the version number. Version numbering on a technology configuration item could be a simple incrementing of a number. Within a given version number category (major, minor), these numbers are generally assigned in increasing order and correspond to new developments in the software. If the base version of a technology configuration item is 1.0, on implementation of minor changes the version must change to 1.1, 1.2, 1.3 and so on. Whereas on implementation of a major change, the version shall change to 2.0 and so on.

Baselining

A "baseline" is an agreed description of the attributes of a product, at a point in time, which serves as a basis for defining change. A deliverable (e.g. work product) is baselined when it reaches a predefined milestone in its lifecycle. A baseline can be a single work product or a set of work products that can be used as a logical basis for comparison. Every single item that was identified as a technology configuration item and exists in a validated form, must be included in the baseline.

A baseline can only be established at a defined validation milestone in project life cycle project. Hence it is an event-defined milestone and not time defined. A validated record of a baseline is a document required at a transition point in the lifecycle. It is meant to achieve a clean and precise handover from the end of one major phase to the beginning of another. It is meant to ensure that the complexity of what is handed over is fully captured in the form of a record (the baseline record).

Deliverable baselining involves the following activities:

• Identify key deliverables: Select those deliverables that must be baselined and at which phase it must be baselined.
• Define standards for each deliverable: Set the requirements for each deliverable and the criteria that must be met before the deliverable can be baselined.
• Identify the critical transition points where the baselining is mandatory
• Intermediate baselines can be established based on degree of complexity and the frequency of the changes happening in the project or process.

It is not necessary that each version of the document must appear in one of the baseline record. In case one of the technology configuration items is revised to correct a defect and the change does not have a major delivery impact, the baseline need not be taken. Subsequently if the technology configuration item is modified as part of a major revamp, the version after revision must be part of next baseline and the intermediate version should not appear in any of the baselines.

Managed

A technology configuration item could be any service component, infrastructure element, or other item that needs to be managed in order to ensure the successful delivery of services.

Controlled

The documented output of an action which does not undergo version control and is plainly maintained as evidence of reference is a controlled item.

Check in – Check out

• Check out action must be performed whenever there is a need for any modification on the work product / documents.
• After making the necessary modifications, the work products should be checked in, into the technology configuration management system.
• On completion of the modifications, the work product must be reviewed for its correctness and completeness.
• The author of the document should check out the work product to incorporate the review comments (if any).
• Proper versioning must be done on the work product based on the type of change (major / minor).
• The Configuration Manager must apply baselines as per the defined criteria mentioned in the Technology Configuration Management Plan
• The above steps must be repeated for the next baseline.